1. Field of the Invention
The present invention relates generally to the field of computer software. More specifically, the invention relates multi-threaded, multi-tasking synchronization techniques in computer software.
2. Description of the Related Art
One of the challenges in building a multi-threaded application or a multi-tasking application is controlling access to per-process protected data, particularly file handles or dynamically-allocated data structures. When reading from and writing to such objects or data locations, the underlying operating system should provide a safe means of maintaining the validity and coherency of the data. A coherency/validity problem may exist when a read is performed prematurely before a critical write or when a write is likewise performed before a read which required the previous data state. One such mechanism for preventing data coherency problems is known as a read/write lock.
Win32 (i.e., 32-bit Windows.TM. operating systems) based software is provided the advantage of having synchronization objects available to threads and processes running in a Win32 environment (such as Windows NT.TM.) (Windows, Windows NT are trademarks of Microsoft Corporation). One such synchronization object is known as a mutex or mutual exclusion object. In a multi-threaded environment, the prior art typically specifies that a single mutex be used to service all threads and/or processes requiring access to the same protected data location(s). Only a single thread or process may own the mutex at any one time with other threads/processes put into a wait state. The use of exclusive access mutexes only partially overcomes a deficiency in certain operating systems, which is the lack of true read/write locking mechanisms for data. Such exclusive access with a single mutex prevents multiple "readers" (threads or processes requesting a read from a data location) from accessing the same data (location) simultaneously and thus, exclusive access mutexes introduce a latency interfering with a multi-threading advantage, that of quick concurrent thread processing. A further problem known as priority inversion, which is described in FIG. 3(a) below, also exists with single mutex only systems.
Having a mutex and no other synchronization object for each shared resource (data location/object) is not always a viable solution since the problem of deadlock where one thread claims the mutex of object A and waits for the mutex of object B, while a second thread claims the mutex of object B and waits for the mutex of object A is quite possible. Further, the chance of deadlock increases with every shared resource, and consequently every new mutex added.
Without read/write locks in the operating system, and given the deadlock contention issue, most applications are constrained to having a single mutex in order to guarantee data coherency for both read and write requests. When other synchronization objects are provided by the operating system, a common solution has been to use a mutex to protect the other synchronization objects and data used to implement a read/write lock patch, as described in "Efficient Synchronization Techniques for Multithreaded Win32-Based Applications," Daniel Glasser, Microsoft Systems Journal, February 1995. However, this approach suffers in that it defeats another operating system feature that allows a thread to wait for multiple thread synchronization objects simultaneously. Thus, what is needed is an efficient read/write software lock mechanism that can be executed within any multi-threaded, multi-tasking operating system. Such a mechanism should be portable and of low-latency particularly when the application utilizing it has real-time constraints.